home *** CD-ROM | disk | FTP | other *** search
/ Visual Basic Controls / Visual Basic Controls.iso / vbcontrol / proa4109 / knownbug.txt < prev    next >
Encoding:
Text File  |  1998-04-06  |  7.3 KB  |  199 lines
  1. Known bugs and limitations in Project Analyzer 4.1
  2. ==================================================
  3.  
  4.  
  5. NOTE THAT THIS LOOONG LIST INCLUDES MOSTLY MINOR BUGS THAT OCCUR
  6. IN SOME SPECIAL CASES ONLY. 
  7.  
  8.  
  9.  
  10. I like to be honest. The truth is there are some disadvantages in the
  11. analysis method Project Analyzer uses. The analysis method is called
  12. static (design-time) analysis, and there are some things it can't do. 
  13.  
  14. Project Analyzer performs mostly well, but it isn't perfect. I haven't
  15. seen any perfect analyzers, and I don't believe I ever will.
  16.  
  17.  
  18. Please report any new bugs to vbshop@aivosto.com. If you can, please
  19. attach a short code file or project to facilitate debugging. 
  20.  
  21. Some of these limitations are on a to-do list, some can't be fixed at
  22. all. 
  23.  
  24.  
  25.  
  26.  
  27.  
  28. ===========
  29. Limitations
  30. ===========
  31.  
  32. - Project Analyzer has no known practical limit to the size of projects 
  33.   it can handle. It has been successfully used with projects that are 
  34.   several MB in size, and have over 100,000 lines of code.
  35. - The size of variable, constant and procedure names is restricted to 64
  36.   characters to save some memory. Longer names are truncated.
  37. - Super Project Analyzer can handle a group of max 50 projects at once
  38.  
  39. - There are limits to the number of references in one procedure and
  40.   module. There is no hard limit for the total number of references.
  41.  
  42.   Procedure reference limit:         Max
  43.   From a procedure to other procs    100 calls / procedure  Fan-out
  44.  
  45.   Module reference limit:            Max
  46.   From a module to other modules     100 refs / module      Fan-out
  47.   To a module from other modules     200 refs / module      Fan-in
  48.  
  49.   If you are concerned if your LARGE project has met one of these
  50.   limits, see the Metrics window for structural fan-outs = 100 or 
  51.   structural fan-ins = 200.
  52.  
  53.   Variable, constant, Type and Enum references are not limited.
  54.  
  55.  
  56. ==================
  57. Known misbehaviour
  58. ==================
  59.  
  60. - Long lines don't word wrap on some report types
  61. - Long procedural call tree reports (All procedures) can hang the computer
  62. - In the hypertext window, letters in DefType statements may be 
  63.   mistaken for one-letter variable names
  64. - In the hypertext window, if you have two different definitions with the
  65.   same name (e.g. Form1.MyVar and Form2.MyVar), the program may
  66.   highlight the both in red when only the other one should be
  67.   highlighted. This bug has no effect on the real analysis. 
  68. - If a local var/const has the same name as the procedure it's in, the
  69.   procedure name will be mistaken for the var/const name in the
  70.   Hypertext window and Project Printer. This has no effect on the
  71.   analysis, though.
  72. - If a procedure and a module have the same name, this can result in 
  73.   erroneous references to the procedure instead of the module.
  74. - Variants are classified as non-object variables, even if they contain
  75.   an object, because there is no way to detect this at design-time.
  76.   This may lead to minor flaws, like with the below code:
  77.  
  78.    Dim v as Variant
  79.    Set v = Form1
  80.    v.Caption = "This is my form"
  81.      
  82.   Here the last statement is considered an assignment to v, although,
  83.   strictly speaking, it's a reference to v (and assignment to Caption). 
  84.   Fortunately, this doesn't do much harm. If v was defined as 
  85.   Dim v as Form (instead of Variant), the reference would be detected
  86.   just OK.
  87.  
  88. - In the following code
  89.   For x = 1 to 10 : Debug.Print "Hello world" : Next
  90.   X is reported as Used only in assignment, even if it really is
  91.   both assigned and referenced by the For...Next statement.
  92.  
  93. - If an array defined as New ObjType is later ReDim'd, the ReDim doesn't
  94.   count as an assignment but a reference, even if the ReDim creates new
  95.   objects in the array.
  96. - ReDim statements without the Preserve keyword may cause Project
  97.   Analyzer to think there is an extra local array variable. Example:
  98.  
  99.   ' (declarations)
  100.   Dim MyArray() As Integer
  101.  
  102.   Sub MyProcedure()
  103.   ReDim MyArray(100) As Integer
  104.  
  105.   Project Analyzer may think MyArray is a new array if 
  106.   1) the original Dim is located in the (declarations) section of 
  107.      another module, AND
  108.   2) the module with Dim comes after the module with ReDim in your MAK
  109.      or VBP file.
  110.  
  111.   The cure is to swap the order of the modules in MAK/VBP, or use 
  112.   ReDim Preserve, or mark the ReDim statement with '$ USED (see 
  113.   project.hlp for Comment directives). There is no way in the current 
  114.   2-phase analysis architecture of Project Analyzer to fix this problem.
  115.  
  116.  
  117. ===============================
  118. Deficiencies in VB 3.0 features
  119. ===============================
  120.  
  121. - The Summary report shows somewhat distorted figures for 
  122.   1. Global Name Table: Type definitions and DLLs declarations are
  123.      not calculated correctly.
  124.   2. Global Symbol Table: type definitions are excluded, and everything 
  125.      else is assumed to take 10 bytes of memory.
  126.   Use freeware VB Space (by Gregg Irwin) for more exact calculations.
  127.   Available at http://www.aivosto.com/vblinks.html
  128. - Can't analyze files saved as binary. Save as text instead.
  129.  
  130.  
  131. =======================
  132. Unsupported VB features
  133. =======================
  134.  
  135. - Line labels. If you use them, you may get incomplete results on those
  136.   lines that have a label. Line numbers are supported. 
  137. - The [] syntax is not fully supported. For example, in the below code,
  138.   Dim X As Integer
  139.   Print [X]
  140.   the reference to variable X is not detected because of the [] syntax.
  141.  
  142. ===============================
  143. Unsupported VB 4.0/5.0 features
  144. ===============================
  145.  
  146. - Line continuation character "_"
  147.  
  148. - Late-bound references. Example:
  149.   Forms(2).DoSomething 
  150.  
  151.   Project Analyzer can't know which form the call goes to, because 
  152.   Forms(2) may be of any of your forms. This applies to all object
  153.   references that are of a general type (e.g. As Form, As Object) 
  154.   and not a specific type (As MyForm, As MyObject).
  155.  
  156. ===========================
  157. Unsupported VB 5.0 features
  158. ===========================
  159.  
  160. - Controls on UserForms (.dsr/.dsx files)
  161. - Inherits statement (polymorphism) supported partially. A procedure that 
  162.   implements an interface procedure is dead only if the procedure it 
  163.   implements is also dead. That's because polymorphed calls are bound 
  164.   finally at run-time.
  165.  
  166. ==============
  167. The FRX window
  168. ==============
  169.  
  170. - Supports the most usual data types and controls, like PictureBox.Picture,
  171.   ListBox.List, ListBox.ItemData, TextBox.Text, MouseIcon etc.
  172. - Some properties that are not supported (others exist):
  173.   AniButton.Picture, SSCommand.Picture
  174.  
  175. ======================
  176. Help Compiler Warnings
  177. ======================
  178. You can ignore the following warning in HCW.EXE (if you use RTF to Help
  179. reports):
  180.  
  181. 'HC2002: Note: 
  182.     The keywords "xyz" and "Xyz" are identical except for case. 
  183.     Help Workshop has modified one keyword to match the other.'
  184.  
  185.  
  186. ================
  187. For best results
  188. ================
  189.  
  190. - Always declare your local variables (use Option Explicit)
  191. - Always save your files as text (VB 3.0)
  192. - Use MS Word as your RTF editor
  193. - Wait for the analysis to end completely (it has 2 phases)
  194. - Use correct VB syntax. Project Analyzer relies on the correctness of
  195.   your code. If you analyze a project that VB cannot run, you may get
  196.   funny results.
  197. - Use good coding practice. Put only one statement on one code line. 
  198.  
  199.